組織在面臨需要更換現有軟體系統時，經常陷入半完成技術更換的循環。我們的經驗教導我們一系列模式，讓我們能打破這個循環，這些模式仰賴：有意識地了解取代傳統軟體的預期成果、將這個取代分為數個部分、逐步交付這些部分，以及改變組織文化以了解變更是不變的現實。

在將巨石分解成較小的服務時，最困難的部分實際上是分解存在於巨石資料庫中的資料。若要提取資料豐富的服務，遵循一系列步驟很有用，這些步驟會隨時保留資料的單一寫入副本。這些步驟從在現有巨石中進行邏輯分離開始：將服務行為拆分為一個獨立的模組，然後將資料分開到一個獨立的表格中。這些元素可以分別移到一個新的自主服務中。

大型主機系統持續執行世界上大部分的運算工作負載，但要新增新功能來支援不斷成長的業務需求通常很困難。此外，讓它們增強功能緩慢的架構挑戰也讓它們難以替換。為了降低所涉及的風險，我們應使用逐步方法來取代傳統系統，逐漸用現代技術的實作來取代傳統功能。此策略要求我們在大型主機系統中引入縫隙：我們可以在其中將邏輯流程轉移到較新的服務。在最近的一個專案中，我們研究了幾種方法，將這些縫隙引入長壽的大型主機系統。

由於單體系統變得過於龐大而難以處理，許多企業開始將它們分解為微服務架構樣式。這是一趟值得的旅程，但並不容易。我們了解到，要做好這件事，我們需要從一個簡單的服務開始，然後繪製出基於對業務而言重要的垂直能力且容易經常變更的服務。這些服務一開始應該很大，最好不依賴於其餘的單體。我們應確保遷移的每一步都代表對整體架構的原子性改進。

我以前的同事 Dave Farley 一直經營著一個越來越受歡迎的軟體開發 YouTube 頻道。這是很好的素材，非常符合我的觀點，畢竟他的經驗對我的思考有很大的影響。我們討論了關於軟體工程當前角色的一系列主題，特別關注我目前支持的三個大型寫作專案：資料網格、分散式系統模式和傳統取代模式。

資產擷取是開發 StranglerFigApplication 的策略。您可以將許多應用程式視為管理一組關鍵資產。薪資系統負責員工，交易系統負責交易，租賃系統負責租賃。若要逐步切換到新系統，您可以從識別您將從新系統開始的一組資產開始。通常，最適合開始的資產是簡單資產（因為它們可以快速開始）或那些難以使用舊系統處理需求的資產。

歷史或多或少是廢話

-- 亨利·福特

我最近收到一位 UML Distilled 讀者的不滿意電子郵件。當一位憤怒的讀者後悔購買，更別說閱讀我偶爾的智慧之語時，這對我來說從來都不是美好的一天開始。但這位讀者的抱怨特別有趣。他具體的抱怨是我的「不必要的歷史」。

在處理舊系統時，找出並建立接縫非常有價值：我們可以在這些地方變更系統行為，而不用編輯原始碼。找到接縫後，我們可以使用它來中斷依賴關係，以簡化測試、插入探針以獲得可觀察性，以及將程式流程重新導向到新模組，作為舊系統置換的一部分。

最近我花了一些時間與我曾經最喜歡的 Thoughtworks 專案之一。這是個在 1998 年啟動的專案，當時使用的是新的 J2EE 技術。多年來，它有著一段引人入勝的歷史：從 EJB 開始，將它們移除，外包到班加羅爾，再回到芝加哥。許多人進出過這個專案，專案的人數在 6 到 60 人之間變化。總體而言，這個專案投入了超過 300 個員工年的工作，規模約為 100 KLOC。

當辛蒂和我前往澳洲時，我們在昆士蘭海岸的熱帶雨林中待了一段時間。這個地區的自然奇觀之一是巨大的絞殺榕。它們的種子會在樹的上方枝幹中萌芽，並逐漸沿著樹幹向下生長，直到在土壤中生根。經過多年，它們會長成奇特而美麗的形狀，同時絞殺並殺死作為它們寄主的樹。